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Preface 

The Report on Business Process Re-engineering published by the Department of Administrative 
Reforms (DAR&PG] in November 2010 was a concept paper based on 11 th report of second 
Administrative Reforms Commission(ARC] that outlined the main purpose and principles of 
process reengineering in the Government. 

• For every function a government department performs, there should be a step-by-step 
analysis of each process to ensure its rationality and simplicity. 

• Such analysis should incorporate the viewpoints of all stakeholders, while maintaining the 
citizen-centricity of the exercise. 

• After identifying steps which are redundant or which require simplification, and which are 
adaptable to e-Governance, the provisions of the law, rules, regulations, instructions, codes, 
manuals etc. which form their basis should also be identified. 

• Following this exercise, governmental forms, processes and structures should be 
redesigned to make them adaptable to e-Governance, backed by procedural, institutional 
and legal changes. 

The current document, Government Process Architecting Framework (GPAF'), builds on the earlier 
generic guidance and provides a systematic guide for process architecting in government entities. 
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1 Executive summary 


1.1 Background 

The National E-governance Plan (NeGP] envisages several Mission Mode projects (MMPs] that use 
modern technology to simplify delivery of services to citizens. The success of these projects not 
only depends on technology but also on the removal of redundant processes and the introduction of 
new or modified processes that overcome past inefficiencies, and optimally use the new technology. 
In its eleventh report, the Second Administrative Commission (ARC], observed that one of the 
lessons learnt from ongoing or completed e-governance projects was that "business process re¬ 
engineering is a pre-requisite in case of complex projects". The commission also went on to 
emphasize that business process re-engineering "would form the backbone of e-governance 
initiatives" and that "business processes would in effect be changed fundamentally to allow the 
efficiency and transparency gains associated with e-government". 

This document, Government Process Architecting Framework (GPAF] focuses on process 
architecture. It prescribes a standard methodology for re-architecting (or reengineering] the 
operational processes in a government organization. 

1.2 Need for a standard organization-wide framework 

In general, process changes are required when: 

• The current processes are sub-optimal, and can be made more efficient even without 
introducing new technology. 

• Technology introduces new features and capabilities that can make processes simpler and 
quicker. 

• Operational siloes prevent seamless flow of information among organizations and within 
the organization. 

• Duplication of services and resources between various wings of the government prevent 
standardization, and escalate cost. 

While re-engineering processes, as part of an MMP, is certainly a step in the right direction, doing so 
individually is not the optimal route. The numerous functions and processes in the government are 
distinct yet inter-linked. Changes in one process can have an unintended effect on another. It is 
this inter-linkage between processes and functions that drives the need for a standard 
organization-wide process architecture framework that spans individual projects: 
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• Organizational functions are inter-related - changes in one affect another. Therefore 
process re-design requires an organization-wide approach. 

• Though processes differ, there are conceptual similarities between all processes. For 
instance, all of them receive inputs, generate outputs, influence information, and perform 
some kind of services. This common conceptual foundation (discussed ahead] also 
supports the evolution of a common architecting methodology. 

• All processes drive the reason for their existence from the organizational mission. It is the 
purpose of a process architecting framework to trace this connection and use it to 
significantly re-model existing processes or even eliminate unnecessary ones (that are not 
related to the mission]. This step is sometimes glossed over by architecture teams. A 
standard framework will make it mandatory for architecture teams to perform this vital 
step. 

• Process rationalization is a complex task that connects business processes with 
organization strategy and technology. A standard framework will ensure that teams 
entrusted with this important task exercise due diligence and rigor. 

• A standard framework also facilitates the creation of a repository of good practices that can 
be re-used. 

It is therefore important that the framework does not recommend an MMP-wise approach to 
process design but an organization-wide (or sector-wise] generic approach. 

1.3 Conceptual foundation 


The concept of 'process architecture’ (and hence 'architecting'] is to be viewed in the context of 
'enterprise architecture'. The eleventh report of the second ARC emphasizes this relationship by 
stating that enterprise architecture should serve "as an ideal platform for initiating the business 
process re-engineering exercise". It also goes on to say, "A well constructed enterprise architecture of 
an organization helps in understanding the linkage between vision, the mission and the functions of an 
organization. This exercise captures the inter-dependencies between the different parts of an 
organization. It helps in appreciation of the linkage between the objectives and activities of an 
organization and the relationships between the organizational processes and the technology." 

Enterprise architecture is a rapidly emerging discipline that views an enterprise along several 
dimensions - strategy, organizational structure, technology, and business (or operational] 
processes. Enterprise architecture describes each of these views in a distinct yet related manner. 

The fundamental principle of the GPAF is to work backward from the vision and goals of the 
organizations to the desired services and finally to the underlying processes and information 
requirements. By linking the goals of the organization to the services, it builds a solid rationale for 
eliminating unnecessary services, introducing new ones, and streamlining existing ones. By further 
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drilling down to the constituent processes, it provides a mechanism for deciding which process 
improvements will result in maximum value. Next, information requirements are studied because 
process optimization cannot be carried out without tailoring data inputs that go into processes. 
Finally, suggestions are made regarding the areas where computerization can help and broad IT 
application specifications defined. 

The goal of process architecture is to rationalize the various activities and information 
requirements in an organization so that they effectively function together to produce the desired 
services. 

1.4 The 'sector-as-a-whole' view 


The Government of India is structured as a hierarchy of organizational units at various levels of 
aggregation - sections, divisions, departments, ministries, sectors, and state and union 
governments. Also included in this structure are autonomous bodies and attached/subordinate 
offices. 

The GPAF recommends that the sector be treated as a seamless entity for the purpose of process 
rationalization. This means that process rationalization may affect processes that span multiple 
departments within the sector and can eliminate processes that are common between departments 
within the sector. It also implies that when a sector contains two or more MMPs, the framework 
should be applied seamlessly across the MMPs (not used individually by each MMP], 

Each sector will be responsible for undertaking its own process re-engineering initiative. However, 
the DAR&PG will invite feedback and collate policy level generic procedural reforms from 
Ministries/Departments to inculcate the necessary changes in the relevant policy. 

1.5 Methodology 


Thus, in GPAF, process architecture development involves transforming processes across a sector. 
This transformation is to be executed as a project using the six-phase GPAF methodology: 

i. Establish team and initiate project 

ii. Define the strategic intent and scope of the architecture 

iii. Analyze current (baseline] process and data architecture (As-is] 

iv. Evolve the target process architecture (To-be] 

v. Evolve IT solution architecture 

vi. Formulate the implementation plan 
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1. Establish team and 
initiate project 


3. Analyze the_ 

process architecture 
(As-is) 



5. Evolve the IT solution 
architecture 


2. Define strategic 
purpose and scope 


4. Evolve the target 
process architecture 
be) 


6. Implement the Proces: 
Transformation Plan 


1.5.1 Set up team and initiate project 

This is the first phase in this methodology. It establishes the overall governance framework 
including the core team required to guide the architecture development. The phase includes 
establishing the overall governance framework, educating Executive Heads on the process and time 
commitment, selecting the Executive Sponsor, evolving the overall architecture mission, and 
forming the core execution team. 

1.5.2 Define strategic intent and scope 

In this second phase, the scope and strategic intent of the process architecture is defined. Since 
sectors may often cover a vast spectrum of functions or processes, not all of which need to be 
covered by the project, the focus of the architecture must be defined in the beginning. The phase 
aims at developing a comprehensive understanding of the relevant sector goals and desired 
outcomes, major strategic transformational opportunities, performance gaps, mandates and 
drivers, and common or mission-specific services. The phase consolidates these factors to lay the 
context and scope that determine the remaining steps of this methodology. Gathering and analysis 
of stakeholder needs and business drivers contributes in identifying strategic transformational 
opportunities. 

1.5.3 Analyze current process architecture (As-is process) 

The third phase analyses the current or "as is” environment. It links the performance and strategic 
goals of the Sector with specific processes, functions, services, and data requirements. The key to 
success in this phase is to analyze and document the requirements to the lowest level of detail 
necessary to form actionable recommendations. 


Department of Administrative Reforms and Public Grievances 


May 2012 


9 













Government process architecting framework 


1.5.4 Evolve the target process architecture (To-be-process) 

This phase uses the findings from the previous phases to recommend a desired or target process 
architecture. The phase involves: 

• Identifying the target state processes 

• Deriving the information requirements (data architecture) 

• Harmonizing the processes with the data architecture to arrive at the target process and 
data architecture 

The objective will be to achieve the strategic transformational opportunities identified earlier, and 
to maintain compliance with information assurance and security mandates. 

1.5.5 Evolve IT solution architecture 

This phase includes activities that help the architect describe the IT solutions that are required to 
implement the target process and data architecture derived in the previous phase. The description 
is kept at a top-level, which can be used later by application designers to arrive at the detailed 
specifications of the IT solutions. Accordingly, this phase defines the broad service requirements, 
interfaces with the external world, system functionality, system boundaries, data entities, and 
interfaces between systems. As far as possible, the solution description should be kept vendor 
agnostic. 

1.5.6 Prepare the transformation plan 

The GPAF concludes with an implementation plan. The plan consolidates the findings, identifies 
associated transition options, assigns responsibilities, charts out milestones, and prescribes a 
monitoring framework. 

1.6 Conclusion 


The GPAF describes a six-phase methodology to rationalize the processes within a sector. 
Rationalization implies drawing a line of sight between the sector's goals and the operational 
processes so that redundant processes that do not add value are eliminated, and processes that are 
essential to the delivery of the critical services are optimized. Information requirements are spelt 
out in a structured manner that eliminates duplication and ensures security. Finally, by deriving 
the IT application requirements from the desired processes, the GPAF paves the way for managing 
the overall IT investment optimally. 
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2 Introduction 


2.1 Purpose of the document 


This document, Government Process Architecting Framework [GPAF], prescribes a methodology for 
re-architecting (or reengineering] the operational processes in a government organization. 

2.2 Background 


The National E-governance Plan (NeGP] envisages several Mission Mode projects [MMPs] that use 
modern technology to simplify delivery of services to citizens. The success of these projects not 
only depends on the technology used but also on new or modified processes that overcome past 
inefficiencies and optimally use the new technology. 

It was in this context that the eleventh report of the Administrative Reforms Commission focused 
on the need to conduct a business process reengineering exercise in the Government of India. 
According to the report: 

"the way government institutions conduct their business has evolved over a period of time and is 
codified in different Statutes, Rules, Regulations and procedural manuals enacted or formulated 
over a wide span of time [with many processes even continuing from the colonial period). On the 
other hand, the scope and complexities of governance along with the government machinery have 
expanded during the last few years. The advent of ICT has led to the recognition that these 
technologies provide a unique opportunity to redesign government processes not only to provide 
better services and reliable information to citizens but also to improve efficiency and effectiveness 
within government institutions. 

a. For every function, a government organization performs and every service or information 
it is required to provide, there should be a systematic analysis of each process to ensure its 
rationality and simplicity. 

b. Such analysis should incorporate the viewpoints of all stakeholders, while maintaining the 
citizen-centricity of the exercise. 

c. After identifying steps which are redundant or which require simplification, and which are 
adaptable to e-Governance, the provisions of the law, rules, regulations, instructions, 
codes, and manuals, which form their basis should also be identified. 

d. Following this exercise, governmental forms, processes and structures should be re¬ 
designed to make them adaptable to e-Governance, backed by procedural, institutional 
and legal changes." 

Since rationalizing processes is a complex task and often done in siloes, it was felt necessary to 
evolve a common standard methodology that all government departments could use. The 
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methodology would also synchronize with the Government of India’s strategy on technology and 
communication. This document is an effort to cull together a set of practices that all government 
departments can adopt and customize if required to meet their business architecting needs. 

2.3 Need for a standard organization-wide framework 


While re-engineering processes as part of an MMP is certainly a step in the right direction, doing so 
in siloes is not the optimal route. The numerous functions and processes in the government are 
distinct yet inter-linked. Changes in one process can have an unintended effect on another. It is 
this inter-linkage between processes and functions that drives the need for a standard 
organization-wide process architecture framework that spans individual projects: 

• Organizational functions are inter-related - changes in one affect another. Therefore 
process re-design requires an organization-wide approach. 

• Though processes differ, there are conceptual similarities between all processes. For 
instance, all of them receive inputs, generate outputs, manipulate information, and perform 
some kind of services. This common conceptual foundation (discussed ahead] also 
supports the evolution of a common architecting methodology. 

• All processes drive the reason for their existence from the organizational mission. It is the 
purpose of a process architecting framework to trace this connection and use it to 
significantly re-model existing processes or even eliminate unnecessary ones (that are not 
related to the mission]. This step is sometimes glossed over by architecture teams. A 
standard framework will make it mandatory for architecture teams to perform this vital 
step. 

• Process rationalization is a complex task that connects business processes with 
organization strategy and technology. A standard framework will ensure that teams 
entrusted with this important task exercise due diligence and rigor. 

• A standard framework also facilitates the creation of a repository of good practices that can 
be re-used 

It is therefore important to note that the framework does not recommend an MMP-wise approach 
to process design but an organization-wide (or sector-wise] approach. 

2.4 Core philosophy 


The GPAF adopts the following core principles to guide its strategic direction: 

Charter-driven: The GPAF should be closely aligned with government strategic plans and 
executive level direction. The National e-Governance Plan (NeGP], government policies, 
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department performance goals, and departmental heads give direction to each 
department's business architecture. 

Active collaboration: Adoption of the GPAF is achieved through active participation of 
government organizations. 

Effectiveness and efficiency: Process architecture improves the effectiveness and 
efficiency of government resources. No IT investment should be made without approved 
process architecture. 


2.5 'Sector-as-a-whole' view 


The Government of India hierarchy consists of organizational units at various levels of aggregation 
- sections, divisions, departments, ministries, sectors, and state and union governments. Also 
forming part of the hierarchy are autonomous bodies and other affiliated organizations. A process 
rationalization exercise could span one or more of these organizations. 

Since rationalization involves identifying commonalities between processes and eliminating 
duplicates, the wider the organizational span considered, the more effective the rationalization. As 
a sector is one of the highest levels of organizational aggregation (and yet not high enough to make 
the aggregated entity too complex), the GPAF recommends a consolidated view of the process 
architecture of a sector. As amplified later, this consolidation implies evolving a set of harmonized 
goals across the sector, which when cascaded down helps eliminate artificial and sometimes 
inefficient boundaries between departments. 

A sector is a group of related government entities (such as departments or autonomous bodies) 
that form a unit across which a process re-architecting initiative is to be seamlessly executed. 
Because the entities in a Sector are related functionally or share resources with each other, the 
GPAF expects a sector to offer significant opportunities for process rationalization across 
organizational boundaries. A sector contains a hierarchy of Ministries, departments, autonomous 
bodies, and other organizational entities. 

The following is the list of sectors identified on the 'National Portal of India’ f http: //india.gov.in/ 1 : 

• Agriculture & Cooperation 

• Animal Husbandry & Fisheries 

• Art & Culture 

• Chemicals & Fertilizers 

• Coals & Mines 

• Commerce & Industry 

• Communications & Information Technology 

• Defence 

• Education & Training 

• Employment and Labour 
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• Energy & Power 

• Environment & Natural Resources 

• Finance, Banking & Insurance 

• Food & Public Distribution 

• Forestry & Wildlife 

• Governance & Administration 

• Health & Family welfare 

• Home affairs & National Security 

• Housing & Urban Development 

• Information & Broadcasting 

• External Affairs 

• Law & Justice 

• Petroleum, Oil & Natural Gas 

• Rural Development & Panchayati Raj 

• Science, Technology & Research 

• Social Justice & Empowerment 

• Tourism 

• Transport & Infrastructure 

• Youth Affairs & Sports 


2.6 Methodology overview 


Every sector is required to initiate its own process architecture project and follow the methodology 
outlined in this GPAF document to implement it. A Steering Committee comprising of Executive 
Heads from the sector will oversee the project and set up a working level group to handle day-to- 
day execution. 

The following are the main phases in the GPAF methodology: 

I. Establish team and launch project 

II. Define the strategic purpose and scope of the architecture 

III. Analyze current (baseline] process and data architecture [As-is] 

IV. Design the target process architecture [To-be] 

V. Evolve IT solution architecture 

VI. Formulate the transformation blueprint and its implementation 
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The figure below graphically represents the GPAF phases. 



FIGURE 1: GPAF METHODOLOGY 

The idea of GPAF must be viewed in the context of 'enterprise architecture'. The theory of 
enterprise architecture views an enterprise along several dimensions - strategy, organizational 
structure, technology, and business (or operational] processes. Enterprise architecture describes 
each of these views in a distinct yet related manner. The figure below depicts the various 
components of enterprise architecture. It also illustrates the idea of an individual sector being the 
top-level entity for application of the GPAF. 



The fundamental principle of the GPAF is to work backward from the vision and goals of the 
organizations to the desired services and finally to the underlying processes and information 
requirements. By linking the goals of the organization to the services, it builds a solid rationale for 
eliminating unnecessary services, introducing new ones, and streamlining existing ones. By further 
drilling down to the constituent processes, it provides a mechanism for deciding which process 
improvements will result in maximum value. Next, information requirements are studied because 
process optimization cannot be carried out without tailoring data inputs that go into processes. 
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Finally, suggestions are made regarding the areas where computerization can help and broad IT 
application specifications defined. 

Every organization can be decomposed into functional units, each of which performs a set of 
interlinked activities. There are two related but different ways to classify these activities - 
'functions' and 'processes'. For instance, the accounts function in an organization performs 
activities related to updating the books of accounts of the organization. Activities that are clubbed 
together into a 'function' usually require similar skills. The activities constituting a function are not 
required to be performed sequentially. However, when activities are clubbed together to form a 
sequential chain they form a 'process'. A process usually results in the output of goods and services 
to the external world. These outputs are called 'services'. The content and source of data used by a 
process at various stages is collectively referred to as data architecture'. The network of functions, 
processes, services, and information requirements is collectively referred to as process architecture 
in the GPAF. 

The goal of process architecture is to rationalize the various activities and information 
requirements in an organization so that they effectively function together to produce the desired 
services. 

2.7 Waterfall versus iterative approach 


In the context of process architecture development, two approaches which can be adopted are the 
'waterfall 1 approach and the 'iterative' approach. A waterfall model will look at the six phases in 
sequence. In practice, real life system or process development proceeds iteratively through the various 
stages. A process or system model progresses iteratively from a generic representation to a more 
granular and detailed representation. The usefulness of a process architecture is enhanced if the 
methodology used is iterative and assimilates knowledge gained during the development process from 
consultations, experiential insights, and stakeholder involvement. This GPAF recommends an iterative 
approach as depicted in the figure below: 
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2.8 Definitions 


Activity: An activity is the general term for a unit of work that forms the subject of analysis in the 
GPAF. Activities can be decomposed into sub-activities (which are also called activities]. The 
lowest level to which an activity needs to be decomposed depends on the analyst, though this GPAF 
recommends the One person one place one time [OPOPOT] criteria for determining the granularity 
at which an activity needs to be analyzed. 

Architecting process (or methodology): The formal process (or methodology) for creating or 
modifying architecture (of an organizational unit) 

Architecture: This is the collective term representing the structure of the various components of 
an organizational unit (services, processes, functions, organizational units, information, information 
sources, computer systems, and technology) and their inter-relationships. The ISO/IEC definition 
is: "The fundamental organization of a system, embodied in its components, their relationships to each 
other and the environment, and the principles governing its design and evolution." 

Baseline model: A baseline is the reference state (usually current) against which improvements or 
other changes are compared. Used in the context of process or data architecture, the term baseline 
model refers to the original or initial state of the architecture. 

Consumer: A consumer (of a service) is the external entity (e.g. individual, business firm) or 
internal entity (e.g. function or organizational unit) that utilizes a service. 


Department of Administrative Reforms and Public Grievances 


May 2012 


17 








Government process architecting framework 


Data architecture: The term data architecture refers to the information required by processes and 
the sources of this information. 

Executive Head: An Executive Head is a senior officer in a department with executive decision¬ 
making authority within the sector. In the Steering Committee, the Executive Head represents one 
of the organizations that comprise the sector. 

Executive Sponsor: The Executive Sponsor is a member of the Steering Committee who can 
represent other members of the Steering Committee in other forums. 

Organizational unit (OU): An organizational unit is the general term for an entity (within the 
Government] that has a well-defined management structure. An OU can be as small as a section and 
as large as a sector. The term is used interchangeably with the term organization, though as far as 
possible, the latter term is used for larger OUs (such as departments]. 

Process architecture: Process architecture is the collective term representing the various 
processes (along with their constituent activities], functions, organizational units, and information 
requirements. 

Process flow model: A process flow model is a collective representation of the various processes 
in an organization. 

Process: A process is a group of sequential activities that results in a service. 

Sector Architecture Steering Committee (SASC): The SASC is the apex sector-level body 
responsible for overseeing restructuring of processes within the sector. The SASC consists of 
executive heads from organizational units in the sector. Designed to provide executive leadership, 
vision, direction, and support the SASC sets policy and strategy, secures funding, appoints key 
personnel to the SAWG, and makes other decisions as required. 

Sector Architecture Working Group: The SAWG is a working level body of individuals that 
manage the architecture development process. It typically consists of program managers and 
subject matter experts from within the sector. The SAWG may be extended to include other key 
stakeholders and IT personnel, such as cyber security experts. 

Sector: A sector is a group of related government entities (such as departments or autonomous 
bodies] across which a process re-architecting initiative is to be seamlessly executed. Because the 
entities in a sector are related functionally or share resources with each other, a sector offers 
significant opportunities for process rationalization across organizational boundaries. 

Service: The term service refers to any output produced by an OU for the outside world or for other 
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OUs. Services can be consumed by other OUs (in which-case they are called 'internal services'] or 
by the external world (in which case, they are called 'external services']. 

Use case: A use case is a formal description of steps or actions between a user (or "actor"] and a 
system. 
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3 Phase I: Establish team and initiate project 


3.1 Phase description and purpose 


This is the first phase in the GPAF methodology. As mentioned in the introduction chapter, every 
sector is required to initiate and manage its process architecture development as a formal project. 
Accordingly, the phase 'Establish team and initiate project’ kicks off the project by establishing the 
project governance framework. The phase structures the governance framework, evolves the 
overall architecture mission, and forms the core team for managing the architecture development 
at the working level. 

The Sector Architecture Steering Committee (SASC) is the apex level of the governance framework 
established during this phase. The committee comprises of'Executive heads' from the departments 
in the sector and an 'Executive sponsor' selected from amongst the executive heads. The executive 
sponsor will represent the other executive heads in other forums, and be the link between the SASC 
and the working groups. Since any recommended process changes may result in policy or 
regulatory changes, it is important that the executive sponsor has the influence to champion and 
drive needed changes. 

The Sector Architecture Working Group (SAWG) is another important component of the 
governance framework. It is a standing group containing project managers and subject matter 
experts (SMEs), who manage the architecture development at the working level. 

The primary document deliverable from this phase is the Sector Architecture Mission Statement 
(SAMS], The SAMS clarifies the primary intent of the steering committee. This mission statement 
will be used by working level groups to prioritize the improvement opportunities identified later. 



The following sections explain the phase activities in greater detail. 


Department of Administrative Reforms and Public Grievances 


May 2012 


20 













Government process architecting framework 


3.2 Activities 


The main activities in this phase are: 

i. Establish the Sector Architecture Steering Committee (SASC) 

ii. Formulate the Sector Architecture Mission Statement (SAMS] 

iii. Set up the Sector Architecture Working Group [SAWG] 

iv. Develop the project charter and schedule 

3.2.1 Establish the Sector Architecture Steering Committee (SASC) 

The phase begins with the setting up of a 'Sector Architecture Steering Committee’ (SASC) for 
overseeing the implementation of the GPAF in the Sector. The SASC will comprise of executive 
heads from each department within the sector and their equivalents from other related 
organizational units. 

The executive heads will nominate an executive sponsor from amongst themselves, who should be 
willing to champion process transformation within the sector. The executive sponsor will 
represent the other executive heads on lower-level committees and groups, and will be the link 
between the steering committee and working level groups. The executive sponsor will be a 
visionary leader for the SAWG (described ahead), who will play a key decision-making role in 
determining the direction and scope of the sector architecture. The executive sponsor should 
therefore be a senior official with the authority to make decisions within the sector. 

The steering committee will determine for itself its own schedule of meetings, the list of 
architecture artifacts that need to be approved by it, and the approval process. 

3.2.2 Formulate the Sector Architecture Mission Statement (SAMS) 

It is important for the Steering Committee to specify the intent behind the sector architecture 
development. It does so in a document known as the 'Sector Architecture Mission Statement' 
(SAMS). Some examples of missions that could be considered are 'higher citizen satisfaction', 
'lower costs', or 'efficient operations'. 

The SAMS should be a high-level statement of principles —with the clarity and specificity required 
to guide the architecture development. It is particularly important for sectors that span multiple 
departments, multiple executive heads, and multiple objectives. As different organizations have 
different (though related) motivators and mandates, the SAMS provides the opportunity to arrive at 
a common set of expectations across the departments in a sector that is useful at the working level. 

The steps to formulate the SAMS are as follows: 
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a. Examine the operational and strategic issues facing each executive head 

Since a sector could be a composite of ministries, departments, and other organizations, each 
organizational entity within the sector is likely to have its own specific challenges. A meeting of 
executive heads facilitated by the executive sponsor is an ideal way to determine the issues of 
pressing importance. Issues to consider should include strategic plans, policies, executive orders, 
legislation, and budget priorities. 

b. Synthesize the common challenges across the Sector 

Since the executive heads operate within the same sector, they are likely to face common 
challenges. A meeting called by the executive sponsor is the opportunity to drive consensus on 
common issues or priorities so that all working level groups have a clear direction and do not 
expend time determining the leadership’s intent. 

The executive sponsor will communicate to the executive heads how well designed process 
architecture can help address the issues or challenges faced by the sector and inspire concrete 
actions within the sector. The architecture can help with process optimization, improved 
information sharing, optimal use of investments, and better formulation of services to citizens. 

c. Formulate the Sector Architecture Mission Statement (SAMS] 

The common challenges and issues identified above will form the basis for the mission statement 
driving the architecture design. This statement, called the Sector Architecture Mission Statement 
[SAMS] should be a concise and clear articulation of the top level goals, major challenges or issues 
that the executive heads would like to see addressed by the process architecture. It should be clear 
enough to ensure that the working level groups understands expectations and develops an 
actionable architecture accordingly. Appendix 1 shows a sample mission statement template. 

3.2.3 Establish the Sector Architecture Working Group 

After formulating the Sector Architecture Mission Statement, the Steering Committee will need to 
set up a group at the working level to drive the architecture development process in the sector. 
This is the Sector Architecture Working Group [SAWG], A knowledgeable, enthusiastic and 
constructive SAWG is an essential step for the valid, relevant or implementable. This activity 
involves the executive sponsor selecting the best and brightest subject matter and project 
management experts from departments within the sector. Ideally, all departments and other 
affected organizations need to be represented on the SAWG. 

The composition of the SAWG is crucial to the success of the project. It typically consists of people 
with program management skills, who are subject matter experts in the sector and key sector 
stakeholders. SAWG members should be constructive, able to think outside of a single 
organizational context, good communicators, visionary, and interested in change. The SAWG may 
also consider inviting other subject matter experts for advice, whenever needed, to supplement 
their knowledgebase as they move through the architecture development process. The important 
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element of the SAWG is that it is a functional team having the knowledge and vision to develop an 
actionable architecture document. 

The steps to establish the SAWG are as follows: 

a. Establish the purpose of the SAWG 

It is important to educate the executive heads on the role of the SAWG. The SAWG is the key group 
of working level resources that will help shape and develop the target state for the sector. These 
resources should be domain experts from the sector. Overall, the SAWG members should 
contribute significant amount of time working on the architecture project. 

b. Identify roles required 

The SAWG will contain some or all of the following roles: 

i. The executive sponsor (identified above] 

ii. A chief architect 

iii. One or more business analysts 

iv. One or more process architects 

v. One or more data architects 

vi. One or more application architects 

vii. A project manager 

viii. One or more IT application designers 

Some of these members need to be available on demand and others on a full-time basis. 

c. Identify skills required 

The SAWG is expected to have the following kinds of skills to a varying degree, depending on role: 

• Generic skills: leadership, teamwork, inter-personal skills 

• Functional skills: business cases, business process, strategic planning 

• Enterprise architecture skills: modeling, building block design, applications and role design, 
systems integration 

• Program or project management skills: managing change, project management methods 
and tools 

• General IT knowledge: top-level knowledge of applications, asset management, migration 
planning, and Service Level Agreements [SLAs] 

• Technical IT skills: software engineering, security, data interchange, data management 

• Legal environment: data protection laws, contract law, procurement law, and fraud 

d. Determine personnel to be appointed to the SAWG 

In most cases, the SAWG will be appointed by the executive heads or the executive sponsor. This 
task usually involves active interaction between executive heads (or executive sponsor] and 
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prospective SAWG members to ensure that desired personnel are available and can contribute time 
to the architecture development. 

The SAWG project manager should be a senior officer in one of the departments in the sector. Other 
personnel could be selected from within or outside the government, depending on where such skills 
are readily available. Ideally, the more the government staff, the more influential will be the SAWG. 
However, the need for in-house staff must be balanced with the need for expertise in niche areas, 
such as process re-engineering, and application and data architecture, which could be more readily 
available outside. 

e. Communicate the formation of the SAWG 

Once appointments have been determined, the concerned personnel should be intimated through a 
formal communication channel. This could be via one-on-one conversations with the appointed 
individuals or a group introduction. Subsequent to these meetings, a formal order or other 
communication announcing the formation of the SAWG is essential. The profile of the SAWG 
members should be captured in the SAWG Team Roster (Appendix 2] and published on the project 
portal for common viewing. 

3.2.4 Create project charter and project schedule 

As mentioned earlier, the architecture development within a sector will be managed as a project 
with a documented, detailed plan. The project charter is one of the main constituents of this plan. 
The charter formalizes the SAWG's role in the sector architecture development. It is a statement of 
the scope, objectives, and participants in a project. As it is approved by the Steering Committee, it 
forms the basis of the SAWG's authority. It delineates roles and responsibilities of various 
stakeholders, outlines the project objectives, identifies the main stakeholders, stipulates 
operational ground rules, defines the decision-making structure, and establishes the authority of 
the project manager. 

a. Develop Sector Architecture Project Charter [SAPC] 

The SAPC should include the role of the SAWG members, the roster of the SAWG team, the decision¬ 
making structure for the SAWG, the SAMS, and the preliminary scope of the project. It should also 
explain how the SAPC aligns with the overall mission. Appendix 3 contains a template for 
developing the SAPC. 

b. Create Sector Architecture Project Schedule [SAPS] 

A Sector Architecture Project Schedule [SAPS] is needed to detail the milestones and proposed 
dates for the architecture development. The SAPS will help ensure that the architecture is 
developed within a stipulated timeframe. 
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c. Review and approve the project charter and project schedule 

The project charter and schedule should be reviewed and approved by the Sector Architecture 
Steering Committee (SASC). This approval will authorize the SAWG to commence the project and 
communicate to the affected organizations the governance framework and overall purpose of the 
architecture project. 


3.3 Phase-1 synopsis 


Phase I witnesses the formation of the Sector Architecture Steering Committee (SASC) and the 
Sector Architecture Working Group (SAWG), and the evolution of the project charter and schedule. 
All artifacts are presented to the steering committee, based on whose approval, the SAWG receives 
its authority to manage the project and move to the next phase. 

The table below presents Phase 1 activities at-a-glance. 


s. No. 

Activity 

Inputs 

Outputs 

Activity owner 

Approver 

1. 

Establish the Sector 
Architecture Steering 

Committee (SASC). 

• List of affected 

organizations and 

their Executive Heads 

• Department plans, 

policies, orders 

• SASC 

• Executive 
Sponsor 

• Department 

Heads 

Sector 

leadership 

2. 

Formulate the Sector 

Architecture Mission 

Statement (SAMS). 

• Department plans, 

policies, orders 

• SAMS 

• SASC 

SASC 

3. 

Set up the Sector 
Architecture Working 

Group (SAWG). 

• SAMS 

• Sector organization 

structure 

• SAWG 

• SAWG team 

roster 

• SASC 

SASC 

4. 

Develop the project 
charter and schedule. 

• SAMS 

• Project 
charter 

• Project 
schedule 

• SAWG 

SASC 
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4 Phase II: Define strategic purpose and scope 


4.1 Phase description and purpose 


Phase II details the scope and strategic intent of the process architecture based on the mission 
statement (SAMS] produced by the steering committee. Since sectors may often cover several 
mandates, and a vast spectrum of functions or processes, it is necessary to focus on what is critical 
to the architecture development The phase does so by relating the main goals of the sector to its 
process architecture. Analysis of the current state of the sector throws up major strategic 
transformational opportunities, and performance gaps in the sector, which can be connected to the 
mandates and mission-critical services of the sector. The conclusions are summarized in an 
architecture vision statement. 


1. Establish team and 
initiate project 


3. Analyze the 
process architecture 
(As-is) 


2. Define strategic 
purpose and scope 



5. Evolve the IT solution 
architecture 


4. Evolve the target 
process architecture 
(To-be) 


6. Implement the Process 
Transformation Plan 


The following sections explain the phase activities in greater detail. 

4.2 Activities 


The main activities in this phase are: 

i. Identify architecture components 

ii. Identify stakeholders 

iii. Determine stakeholder requirements 

iv. Conduct organizational capability analysis 

v. Identify strategic transformational opportunities 

vi. Establish performance goals 

vii. Identify project risks 

viii. Determine the target architecture vision 
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The primary input to the phase is the Sector Architecture Mission Statement. 

4.2.1 Identify architecture components 

This step results in an architectural view of an organization. An architectural view is a 
componentized view of the organization. Architecture components may include organizational 
units, functions, processes, services, software systems, and information exchanges. 

The following figure depicts the generic relationship between various architecture components 
(Architecture metamodel]. 



The main deliverable in this step is the 'sector abstract' containing essential top-level details. This 
sector abstract will be used downstream in various phases. Appendix 4 is a sample template of a 
sector abstract. 

4.2.2 Identify stakeholders 

This task identifies those individuals or entities that are likely to be affected, directly or indirectly, 
by the architecture mission (articulated in the SAMS], These ‘stakeholders’ could be from among 
the following categories: 

• Citizens 

• Employees 

• Vendors 

• Others 

The task produces a list of stakeholders, and documents the relationships between them and the 
sector. 
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4.2.3 Determine stakeholder requirements 


Stakeholders may have divergent perspectives on how to overcome the business challenges 
articulated in the SAMS. It is necessary to review the aspirations of different stakeholders and 
assess their respective degrees of influence. This task studies the needs of stakeholders in the 
context of the architecture mission. It produces a statement of stakeholder needs that is critical for 
ensuring that stakeholders stay motivated and engaged during the architecture development 
process. 


It would be useful to categorize stakeholders according to their degree of influence and interest. 
The following figure provides a framework for evaluating stakeholders. Stakeholders can be slotted 
into the four quadrants and appropriate strategies evolved for each quadrant. 


STAKEHOLDER POTENTIAL INFLUENCE LEVEL 


High Low 


High Influence 

4" Low Influence 

& 

& 

High Interest 

High Interest 

Strategy: Maintain support, refine 
communications to align with project goals 
leverage stakeholder influence 

Strategy: Provide information, 
status updates 

<f< High Influence 

4" Low Influence 

& 

& 

4* Low Interest 

4' Low Interest 

Strategy: Actively engage, target 
communications to align with project goals, 
leverage stakeholder influence 

Strategy: Passive relationship 
management 


Depending on the quadrant into which stakeholders fall, the strategies for engaging them can be 
evolved. These could range from working sessions of stakeholders to surveys that collect 
stakeholder data for analysis later. Some of the stakeholders have to be involved right through the 
process, while others need only be involved in the beginning or end. The SAWG can choose the 
engagement process depending on the working environment and precedents. 

A stakeholder catalogue template that illustrates how stakeholder needs are captured is shown in 
Appendix 5. 

4.2.4 Conduct organizational capability analysis (SWOT) 

Once stakeholder needs have been identified, and their role in the project crystallized, a capability 
analysis (Strengths, weaknesses, opportunities, and threats - SWOT) is carried out to identify the 
opportunities for improvement. 

In the here and now (strengths and weaknesses): Identify all strengths and weaknesses 
that exist currently (and are known prior to the architecting process). 

What might be (opportunities and threats): Identify existing gaps and future 
opportunities that are potential strengths. Also, identify the threats that exist, as they are 
potential future weaknesses. 
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Action plan: Based on the SWOT matrix create an action plan that addresses the four areas. 
Strengths need to be consolidated or leveraged. Weaknesses need to be remedied or 
eliminated. Opportunities need to be prioritized and optimized. Threats need to be 
countered or minimized. 



Helpful 

Harmful 


To achieving the objective 

To achieving the objective 

Internal 

(attributes of the 
organization) 

Strengths 

Weaknesses 


Good Now 

Bad Now 


1 Maintain 

2 Build 

3 Leverage 

4 Remedy 

5 Stop 

External 

(attributes of the 
environment) 

Opportunities 

Threats 


Good Future 

Bad Future 


6 Prioritise 

7 Optimise 

8 Counter 


Appendix 6 depicts a sample SWOT report template. 

4.2.5 Evaluate strategic options 

The analysis carried out during the previous tasks of stakeholder needs and the SWOT assessment 
provide sufficient information for the SAWG to identify transformational opportunities at a 
strategic level. Inclusion of a new service, improvement of the service level of a service, automation 
of a functional area or process, reorganization of functions within the sector, rationalization of data 
sources, or introduction of new technology, are examples of such strategic transformational 
opportunities. 

Wherever possible, the prioritization of strategic opportunities should reflect opportunities for 
meeting some of the stakeholder needs, leveraging some of the strengths and opportunities 
identified in the SWOT analysis, removing or mitigating the weaknesses and potential threats 
identified in the SWOT analysis, and otherwise improving performance, reducing cost, and 
enhancing citizen satisfaction. 

Appendix 7 illustrates how to arrive at strategic architecture transformation options. 
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4.2.6 Establish performance goals 

The next task is to map the strategic transformational opportunities identified in the previous step 
to concrete outputs or tasks (called performance goals], A useful performance goal will draw a 
connecting line between the strategic goals of the sector and its investments in information 
technology and other areas. This connecting line will show how strategic performance goals (top 
level goals] are supported by programme level performance goals, which in turn are supported (if 
applicable] by investments. 

GPAF does not propose any particular performance scorecard or measurement system. Any 
existing system of performance measurement can be used if available, or a new one developed. 
Whichever scorecard is used, it should be capable of providing a complete picture of sector 
performance from the highest level of strategic performance down to operational results and 
investment performance. 

4.2.7 Identify risks 

The task identifies high-level risks that could potentially derail the project (e.g. security and privacy 
issues]. Some of the main risk categories are: 

• Performance gaps 

• Service level drop 

• User dissatisfaction 

• Employee dissatisfaction 

• Security issues 

• Privacy considerations 

• Other legal issues 

Working collaboratively with the relevant stakeholders, the SAWG identifies high-level strategies 
for mitigating potential risks. For instance, the SAWG can facilitate discussions to identify adequate 
security controls for addressing potential issues regarding confidentiality, integrity and availability 
of key services and functions. Appendix 8 provides a sample risk catalogue. 

4.2.8 Determine the target architecture vision 

This task produces the final deliverable of this phase - a high-level description of the desired or 
target architecture. It provides an executive summary of stakeholder needs and interactions, and 
the specific strategic opportunities determined in this phase along with the desired outcomes and 
performance indicators. The may use scenarios to describe the outcome of various strategic 
transformational opportunities to clarify the vision. 

The following diagram depicts the relationship between the various artifacts created in this phase 
and explains how they culminate in the Sector Target Architecture Vision. 
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Appendix 9 contains a sample target architecture vision template. 

The STAV should be presented to the Steering Committee for approval. A presentation including 
the Sector scope and strategic objectives should be prepared by the SAWG. The Chief Architect can 
conduct a detailed workshop-based review of these artifacts. 


4.3 Phase-II synopsis 


Phase II identifies the architecture components and stakeholders, determines stakeholder 
requirements, notes strengths and weaknesses, analyzes potential opportunities and threats, 
assesses risks, and summarizes the results in a target vision statement. 


s. No. 

Activity 

Key Inputs 

Outputs 

Activity owner 

Approver 


Identify 

architecture 

components 

• Available documentation 

on sector organization, 

functions, systems, and 

services 

• Interviews with key 

functionaries 

• Sector 

abstract 

SAWG - Chief 

architect 

SAWG 


Identify 

stakeholders 

• SAMS 

• Sector abstract 

• Interviews with key 
functionaries 

• Key 

stakeholder 

list 

SAWG - PM 

SAWG 


Determine 

stakeholder 

requirements 

• SAMS 

• Sector abstract 

• Stakeholder list 

• Interviews with key 

• Stakeholder 

catalogue 

SAWG- PM 

Executive sponsor 
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functionaries 

• Interaction with key 

stakeholders 





Conduct SWOT 

analysis 

• Sector abstract 

• Stakeholder catalogue 

• SWOT 

report 

SAWG - Analyst 

SAWG 


Identify strategic 
transformational 

prospects 

• SAMS 

• SWOT report 

• Strategic 

transformati 

onal 

prospects 

statement 

(STPS) 

SAWG - Analyst 

Executive sponsor 


Establish 

performance goals 

• Organizational abstract 

• SAMS 

• STPS 

• Performance 

scorecard 

SAWG - PM 

Executive sponsor 


Identify project 

risks 

• SWOT report 

• SAMS 

• STPS 

• Risk 

catalogue 

SAWG - PM 

SAWG 


Determine the 

sector target 

architecture vision 

• STPS 

• SAMS 

• Sector target 

architecture 

vision 

statement 

(STAV) 

SAWG - Chief 

Architect 

SASC 
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5 Phase III: Analyze current process architecture [As-is process] 


5.1 Phase description and purpose 


The third phase analyses the current or "as is” environment. It links the performance and strategic 
goals of the Sector with specific processes, functions, services, and data requirements. The key to 
success in this phase is to analyze and document the requirements to the lowest level of detail 
necessary to form actionable recommendations. 


1. Establish team and 
initiate project 



6. Implement the Process 
Transformation Plan 


The following sections explain the phase activities in greater detail. 

5.2 Activities 


This phase consists of the following activities: 

i. Define the baseline function model 

ii. Define the baseline service model 

iii. Define the baseline process model 

iv. Define the baseline data architecture 

5.2.1 Compose the baseline 'function model’ 

A 'function' is a grouping of activities usually requiring similar competencies or knowledge. A 
function defers from a process in that activities comprising a function do not necessarily have a 
sequential dependence between themselves. Examples of functions include accounting, finance, 
procurement, and budgeting. 
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A 'Function model' is a hierarchical representation of all functions in an organizational unit along 
with their constituent activities. Defining the function model implies tracing the function hierarchy 
from the highest level downwards, by exploding the functions into sub-functions and activities. 
Though the appropriate level of decomposition will depend on the complexity of the processes, a 
convenient rule of thumb is the "one-person-one-place-one-time" (OPOPOT] rule. The rule states 
that on reaching an activity that is performed by one person (or system] at one place and at one 
time, it is usually not necessary to decompose the activity further. 

Appendix 10 presents a sample function model. 

5.2.2 Define the baseline service model 


This step examines the key services in an organization and reviews their outputs, inputs, and 
information requirements. The term service refers to any output produced by an organizational 
unit [OU] for the outside world or for other OUs. Services can be consumed by other OUs (in which- 
case they are called 'internal services'] or by the external world ('external services'], 

A 'service model' represents the key external and internal services delivered by a sector. Service 
level agreements (SLAs] and other performance considerations are also included in the 
representation. 

The following are the main steps involved in the preparation of the service model: 

a. Determine outputs of'external' services 

Identify the services consumed by external entities and the needs they meet. Include Service Level 
Agreements (SLAs] wherever present. 

b. Define the outputs of inter-function services ('internal' services] 

Describe how functions cooperate by providing services to each other. Include any operational 
agreements between functions wherever present. 

Appendix 11 presents a sample template of a service model. 

5.2.3 Define the baseline process model 

The next step is to analyze the processes related to the functions and services identified earlier. A 
'process' is a group of sequential activities that results in a service. Like a function, a process is also 
a group of activities. The difference lies in the fact that processes comprise of sequential activities 
while functions represent a cluster of related activities that do not necessarily have sequential 
dependencies between themselves. 

A 'process model’ is a collective representation of the various processes in an organization. It 
describes the activities that comprise the various processes, and the inter-relationships between 
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them. To develop the process model, the architect works backward from the services to determine 
the activity chain that delivers the services. Interactions across organizational unit boundaries or 
functional demarcations should be described so that ownership and accountability can be analyzed. 
These interactions can be described using ‘swim-lane diagrams'. A swim lane diagram, sometimes 
called a cross-functional diagram, is a process flowchart that provides information on who does 
what. In many instances, the analysis of the organizational or functional relationships between 
processes and activities can yield useful insight on current issues. 

Appendix 12 contains a sample template of a process model. 

Besides swim-lane diagrams, a process model also contains use cases to describe a process in detail. 
A use case is a formal description of steps or actions between a user (or "actor"] and a system 
which constitute a process. The user or actor might be a person or something more abstract, such 
as an external software system or manual process. Appendix 13 contains a use case template. 

5.2.4 Define the baseline data entity architecture 

Though a detailed analysis of data architecture is not within the scope of the GPAF, it is imperative 
to identify information requirements at a top level (called the entity level] as no analysis of 
processes can be complete without an understanding of related information inputs. Through the 
documentation of the processes and information flows, the architect should become familiar with 
the information requirements critical to the various processes. Therefore, this GPAF recommends a 
top-level analysis of the data entities referenced by the processes. 

The development of data architecture involves the following sequence of steps: 

a. Determine high-level process information requirements 

This step captures the information exchange between various activities. Though included here, this 
step should be undertaken when the process model is developed. 

b. Identify data sources and establish data relationships 

This step identifies the sources (and data stores] of the various data entities identified in the earlier 
step. It documents how the various services (and therefore processes] reference these data 
entities. Are the various processes ‘creating’, ‘reading’, ‘updating’ or ‘deleting’ (CRUD] these data 
entities? Appendix 15 depicts a sample service-data matrix that depicts this ‘CRUD relationship’. 

5.3 Phase-Ill synopsis 


Phase III defines baseline versions of the function model, service model, process model, and data 
architecture. All documents are submitted to the SAWG for approval to move on to next phase. 
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s. No. 

Activity 

Key inputs 

Primary outputs 

Activity owner 

Approver 

1. 

Define the baseline 

function model 

• Sector abstract 

• Interviews with 

functionaries 

• Baseline 

function model 

SAWG - Process 

architect 

SAWG - PM 

2. 

Define the baseline 

service model 

• Baseline function 

model 

• Services 

catalogue 

SAWG - Process 

architect 

SAWG - PM 

3. 

Define the baseline 
process model 

• Baseline function 

model 

• Baseline service model 

• Baseline 
process model 

• Use case 

catalogue 

SAWG - Process 

architect 

SAWG - PM 

4. 

Define the baseline 

data architecture 

• Baseline function 

model 

• Baseline service model 

• Baseline process model 

• Baseline data 

architecture 

model 

• CRUD model 

SAWG 

Information 

architect 

SAWG - PM 
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6 Phase IV: Evolve the target process architecture [To-be process] 


6.1 Phase description and purpose 


This phase uses the findings from the previous phases to propose the desired or target processes. 
The phase involves: 

• Identifying the target state processes 

• Deriving the information requirements (data architecture] 

• Integrating the processes with the data architecture to arrive at the target process and data 
architecture 

The objective of the phase is to achieve the strategic transformational opportunities identified 
earlier. 


1. Establish team and 
initiate project 


3. Analyze the 
process architecture 
(As-is) 


2. Define strategic 
purpose and scope 



5. Evolve the IT solution 
architecture 


4. Evolve the target 
process architecture 
be) 


6. Implement the Process 
Transformation Plan 


The following sections explain the phase activities in greater detail. 

6.2 Activities 


The phase involves the following activities: 

i. Determine enhancement prospects in the process and data architecture 

ii. Describe the target process and data architecture 
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6.2.1 Determine enhancement prospects in the process and data architecture 

The objective of this activity is to analyze the gap between the current and required processes in 
the context of the strategic transformational opportunities identified in Phase II. The activity also 
proposes required changes to the data architecture. 

The activity involves the following steps: 

a. Align the strategic transformational opportunities to the process and data architecture 

The previous phases and steps resulted in a mix of information at a low-level (on processes and 
data] as well as at a strategic level. The next step is to link the process and data information with 
the strategic information and determine what changes, if any, need to be made. The analysis could 
help identify duplicate processes that connect to the same end goal and hence are redundant. The 
linkage could also result in a refinement of the strategic transformational opportunities. For 
instance, the architects might conclude that a new service needs to be introduced. This will require 
change in the Sector Target Architecture Vision statement, the new version of which will be 
prepared and sent to the Steering Committee for approval. 

b. Determine enhancements to the data architecture 

Through the process analysis, the architect becomes more familiar with the information 
environment of the sector and is in a position to search for data architecture deficiencies. For 
instance, the architect might determine a process-flow to be sound but may notice data 
inconsistencies because the same data is being entered redundantly at two points. 

The intent of this analysis is not to redesign the entire data architecture by making field-level 
recommendations, but to determine the key high-level adjustments necessary to augment the 
process architecture. The key dimensions used for evaluating the data architecture are as follows: 

Accuracy: Data must be correct at all times and should reflect changes as quickly as 

possible. 

Completeness: The data must represent all relevant features of the entity being described. 

Consistency: When a data value is modified all copies of it must be updated as quickly as 

possible 

Precision: The degree of precision must be tailored to the purpose for which the data is 

being used. 

Timeliness: Data queries must have a reasonable response time. 

Validity of data As far as possible, there should be only one official data source per data entity. 
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sources: This will ensure that the data sources can be monitored and their validity 

sustained. 

Security and Sufficient controls must exist to prevent unauthorized leakage of data, 
privacy controls: 


c. Determine enhancements to the process architecture 

The architect should analyze the activities associated with the key processes to determine critical 
'fault points' that may require process optimization. The criteria used to analyze the processes and 
determine improvements could fall into one of two categories: 

i. Functional requirements 

ii. Non-functional requirements. 

Functional requirements 

These are requirements that are based on the functionality demanded. Based on the target 
architecture vision outlined in the STAV document and an analysis of the baseline models prepared 
in Phase III, the architect can identify process weaknesses. 

Several methodologies exist for conducting a functional analysis of the existing processes. 'Value 
stream analysis' is one of the methods in vogue today. As described earlier, any process consists of 
a sequence of activities, each of which is designed to add value to the service it ultimately delivers. 
Value also implies incurring costs, some of which could be unnecessary or wasteful. 

Identification of redundant or 'low value adding' activities: Value stream analysis of a process 
involves examining the process-flow model, and enquiring, at each stage whether cost or value are 
being added. This analysis helps the architect assess the value added by activities in a process, and 
marking out processes for deletion (redundant processes] or modification. 

Non-functional requirement (NFR] 


An NFR is a requirement that is not related to functionality but instead reflects factors that 
contribute to the effective performance of the process. The various NFRs are: 


Characteristic 

Metric 

Design tactic 

Performance 

Consists of 2 components: 

• Throughput: number of instances of 
a service executed in a time period 

• Response time: time taken from 

Poor performance can be the 
result of needless distribution of 
processes, wasteful use of a 
database, delays caused by 
queues. Optimization can involve 
running processes in parallel or 


Department of Administrative Reforms and Public Grievances 


May 2012 

39 




Government process architecting framework 


Characteristic 

Metric 

Design tactic 


request to response 

optimizing databases. 

Availability 

The percentage of time that a process or 
service is ready for use, excluding planned 
down time 

The primary design technique is 
to build redundancy into the 
process. If computerized, 

automatic failover schemes can 
be examined. Design the process 
defensively, i.e. avoid 'Design by 
contract’ but assume that input 
data can be faulty, and design 
accordingly. 

Recoverability 

The ability of a process to be restored to live 
operations after a failure 

One technique is to arrange for 
backup mechanisms. 

Reliability 

The mean time between breakdowns in a 

process 

Identify potential vulnerabilities 
and provide for redundant paths. 

Integrity 

Data integrity 

Reduce data duplication. 

Scalability 

The ability of a process to grow to 
accommodate increased work loads 


Security 

The ability of a process to prevent 
unauthorized access to its contents 


Serviceability 

The ability of the operations team to monitor 
and manage a system or process 

Maintain a record of performance 
and other process characteristics 
so that aberrations can be 

monitored and corrected. 

Usability 

The user-friendliness of the process 

Processes must be documented 
clearly and any user interfaces 
should cater to user 

requirements. 

Portability 

The ability of system managers to move a 
process from one platform to another 
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Characteristic 

Metric 

Design tactic 

Integratability 

The ability to integrate one process with 
another 


Interoperability 

The ability of processes to interact with each 
other 



6.2.2 Describe target process and data architecture 

The next activity in this phase is to document the target architecture based on the process and data 
improvement opportunities identified in the previous activity. The sequence of steps is as follows: 

a. Identify the affected processes 

This step involves listing the processes marked out for change with a summary of the changes 
required. 

b. Modify use cases of the affected processes 

For each affected process, it is necessary to modify the use case descriptions. The use case must 
describe the altered work rules, performance measures, and information exchange of the affected 
process. 

c. Propose the target process and function model 

Based on the use case descriptions, the architect modifies the baseline process model (swim-lane 
diagrams] and creates a target process model. The altered process model could in turn result in 
changes in the function model (logical hierarchy of related activities]. The regrouping of activities 
will be captured in the swim-lane diagrams. Based on the re-grouping, the architect drafts a target 
function model that encapsulates the ideal organizational function hierarchy (a function model 
represents an organizational hierarchy], 

d. Propose practical organizational unit hierarchy 

Because of certain practical considerations, modifying the function model may not be feasible. In 
such cases, the ideal function model could be tuned to give way to practical constraints. The 
resulting function model will represent the new organizational unit hierarchy of the Sector. 

e. Assemble target data architecture 

Iteratively with the process refinement, the architect will modify the data entity model and if 
required (and possible] reorganize the data sources (Appendix 14] based on the changes suggested 
above. 
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The architect should develop a package that summarizes the process and data architectures for the 
SAWG to review. A presentation that includes the process and data architectures should be 
prepared by the architect. This presentation should include a summary of how the business and 
data architectures align with the high-level business and information requirements derived at the 
beginning of this step. The architect should conduct a detailed workshop review of the business 
and data architectures. The SAWG will decide at this point whether to proceed to the next step or 
further refine the process and data architectures. 


6.3 Phase- IV synopsis 


Phase IV identifies target process and data architecture enhancements prospects and recommends 
an appropriate target process and data architecture. All the documents are submitted to the 
Executive Sponsor for approval to move on to next phase. 


s. No. 

Activity 

Key inputs 

Primary output 

Activity owner 

Approver 

1. 

Determine process 
and data 

enhancement 

prospects 

• Baseline process model 

• Baseline service model 

• Baseline data model 

• Process 

enhancement 

prospects 

SAWG - Process 

architect 

SAWG - Data 

architect 

Executive sponsor 

2. 

Describe the target 
process and data 
architecture 

• Target process and 

data architecture 

• Target 
process 

model 

• Target use 

cases 

• Target 

service 

model 

• Target data 
model 

• Target 
function 

model 

SAWG - Process 

architect 

SAWG - Data 

architect 

Executive sponsor 
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7 Phase V: Evolve the IT solution architecture 


7.1 Phase description and purpose 


Implementation of the target process architecture evolved in the previous steps would require 
implementation of new IT systems or modification of existing ones. The activities in this phase help 
the architect identify the required IT solutions, including the services expected from each system, 
how the system interfaces with the external world and with other systems, what data it references, 
and its functionality. The system descriptions are deliberately kept at a black-box level (which is 
why the term IT solution architecture is used instead of system architecture] so that process 
architects do not get bogged down prematurely in unnecessary detail at this stage. Also, as far as 
possible, the solution description should be kept vendor agnostic. 


1. Establish team and 
initiate project 


3. Analyze the 
process architecture 
(As-is) 



2. Define strategic 
purpose and scope 


4. Evolve the target 
process architecture 
(To-be) 


5. Evolve the IT solution 
architecture 


6. Implement the Process 
Transformation Plan 


The following sections explain the phase activities in greater detail. 

7.2 Activities 


The phase contains the following activities: 

i. Evaluate the current IT systems 

ii. Propose the target solution architecture 

iii. Examine transition options 
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7.2.1 Evaluate the current IT systems 

The focus of this activity is to analyze the current IT systems and assess how well those systems 
support the process and data architectures. The activity includes assessing the systems and 
services across dimensions such as strategy, data and technology alignment; service management, 
and maturity. It addresses questions such as: 

• How effectively are the IT systems in the sector delivering value compared to the costs 
associated with operating and maintaining them? 

• How do the current systems interact with each other? 

The following is the sequence of steps for this activity: 

a. Prepare the baseline systems interface diagram 

This task leverages the process and data architecture analysis conducted earlier, based on which it 
identifies the key systems that should be assessed at this stage. The 'Baseline systems interface 
diagram’ is constructed to illustrate how the functionality identified in the process and function 
models is associated with the existing IT solutions. This diagram shows the IT systems in their 
current state and identifies the relationships (e.g. data exchange packages] between them. 

b. Assess performance of current IT systems 

Once the baseline systems interface diagram is prepared, the performance and value of the systems 
is assessed and potential weaknesses identified. This assessment is a critical task in ensuring that 
the proposed systems support the strategic mission of the sector, especially the architecture vision 
outlined in the Sector Target Architecture Vision (STAV] document. The following are some 
important aspects to be borne in mind while assessing the current systems: 

• The information collected should be at a sufficient level of detail to assess the business fit, 
technology fit, and maturity level of the system and should include its management costs. 
Cost data is useful in determining projected cost efficiencies that may result from 
implementing the target architecture. 

• Information being gathered should include any known security issues or risks, and 
stakeholder feedback with regard to overall system performance and alignment with 
operational needs. 

• The assessment should also include an identification of the degree of functional overlap 
with other systems and the extent to which the systems are associated with re-engineered 
or streamlined business processes. 

• Information can be gathered using a variety of methods, including conducting interviews 
with key stakeholders. 

Appendix 16 is a template for conducting an IT systems survey. 
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Appendix 17 provides a framework for evaluating system performance once required information 
is collected. It proposes a scoring methodology, which can help evaluate systems on multiple 
parameters. 

c. Determine adjustments necessary to the current IT solutions 

The next step is to use the system evaluation performed in the previous steps to position the 
systems according to technology fit (if they score high on technological parameters) and business 
fit (if they score high on net business value addition). Using the scores obtained, slot the IT systems 
into one or more of the following quadrants: 

i. Retire: Systems that have outlived their life or are not performing to their potential. 

ii. Consolidate (with other systems): Systems that are useful; but their effectiveness can be 
enhanced by integrating them with other systems 

iii. Reengineer: Systems that are useful, but may need a major technology revamp or re-design 

iv. Target: Systems that do not need major changes and are performing optimally 

The following diagram 


Summary of Systems Scoring 


Consolidate / Retire Target 



Retire " Consolidate/ 50 

Re-engineer 


Based on this analysis, the architect recommends changes to the current IT systems or proposes 
new ones. 

7.2.2 Propose the target solution architecture 

In this activity, the architect uses the analysis carried out in the previous steps to finalize the 
systems that will form part of the target architecture state. In general, the IT solutions 
recommended should be vendor agnostic and capable of being re-used in other sectors. Since 
sector-specific systems tend to involve higher developmental and operational costs, the 
specification of such unique systems should be considered only in situations where there are 
mission critical needs or a lack of available re-usable systems. 

The following is the sequence of steps: 
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a. Identify reuse prospects 

Identify systems and services that have the potential to be re-used between departments and 
sectors. Also, locate systems and services provided by other sectors that can be re-used. This can 
lead to considerable rationalization across the Government of India, if implemented judiciously. 

b. Specify high-level technology and information standards 

High-level technology and information standards for the target architecture should be specified 
with the goal of maintaining alignment with the strategy, process, and information requirements 
defined in the previous steps. 

c. Identify required system components 

Based on the improvements recommended in the existing systems, identify the new systems or 
system components that are required. Selecting target-state systems may include carrying forward 
an existing system to the target state, consolidation of multiple systems to reduce the total number 
of systems supporting a function, or identification of a new high-level system requirement 
associated with automation of business processes. 

d. Establish inter-system relationships 

The final task in defining the IT solution architecture is to define the relationships between systems 

and services within the context of the overall boundaries of the sector. The result of this step is the 
'Target System Interface Diagram'. 

7.2.3 Evolve transition options 

This activity includes guidance on evolving options to transition from the current solution 
architecture to the proposed one. These transition options could include specific system 
integration projects, formal partnerships (e.g. with vendors), or development of policies. The 
activity consists of the following sequence of steps: 

a. Propose intermediate transition options 

Transition options represent paths from the current state to the desired state. They are based on 
the findings from the study of the current systems, and should be categorized according to the 
findings. Findings can represent almost any issue, from outdated technologies, through poor 
business process fit, to redundancies. Specifically, they consist of the strategic transformational 
opportunities, the business and information opportunities, and the IT solution architecture. 

b. Compare transition options 

Transition options can be compared on the basis of three criteria - value, cost and risk. 

• Value: For each transition option, a value estimate is derived for each strategic focus area. 
This may require additional input from key stakeholders. 
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• Cost: Besides development and maintenance costs, this may also include costs of retiring 
obsolete systems. Cost estimates developed in the earlier steps can be reviewed and used at 
this stage. 

• Risk: Risk analysis is performed for each transition option that includes the identification of 
the top risks in terms of overall impact. This involves assessing the likelihood of the 
occurrence of the risk, along with assessing the impact on both the cost and value of the 
transition option. Risks are then rolled up to obtain an overall likelihood and cost/ value 
impact. 

c. Develop prioritized implementation recommendations 

The architect will review the results of the cost/ value/ risk analysis with the SAWG members to 
select and sequence the transition options. The results should be further reviewed with 
stakeholders to build support for the recommendations. 

The output of this stage is a document that summarizes the baseline and target IT solution 
architecture and provides an overview of the transition considerations, alternatives, and 
recommendations. This should include the artifacts that describe the target IT solution architecture 
and its alignment with the process requirements. 

7.3 Phase-V synopsis 


Phase V assesses the current IT applications environment within the sector, and assembles the 
target solution architecture. All documents are submitted to the Executive Sponsor for approval to 
move on to next phase. 


s. No. 

Activity 

Key inputs 

Primary outputs 

Activity owner 

Approver 

1. 

Evaluate the current 
IT systems 

• Baseline process model 

• Target service model 

• Target process model 

• Target entity model 

• Baseline IT 

systems survey 

• Systems 
interface 
diagram 

• Current IT 

systems 

performance 

report 

SAWG - IT 

applications 

architect 

SAWG - PM 

2. 

Propose the target 
solution architecture 

• Baseline process model 

• Target service model 

• Target process model 

• Target entity model 

• Current IT systems 

• Target IT 

solution 

architecture 

SAWG - IT 

application 

architect 

SAWG- PM 
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performance report 




3. 

Examine transition 

options 

• Target IT solution 

architecture 

• Architecture 
transition paths 
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8 Phase VI: Prepare the transformation plan 


8.1 Phase description and purpose 


The GPAF concludes with an implementation plan. The plan consolidates the findings, identifies 
associated transition options, assigns responsibilities, charts out milestones, and prescribes a 
monitoring framework. 


1. Establish team and 
initiate project 



The following sections explain the phase activities in greater detail. 

8.2 Activities 


This phase includes the following activities: 

i. Document and distribute the draft transformation blueprint for review 

ii. Collect and analyze feedback 

iii. Develop the final transformation blueprint 

iv. Brief steering committee and obtain approval 

8.2.1 Document and distribute the draft 'Transformation blueprint’ for review 

The draft Transformation Blueprint is distributed for review to the SAWG, executive heads and 
executive sponsor. During the review process, a document review form may be used to collect 
review comments and change requests. The blueprint will take the form of a report containing the 
following: 
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• Prescribed recommendations: Changes to process architecture and recommended 
technology solutions 

• Work-breakdown structure (WBS]: Breakdown of work items with roles and 
responsibilities wherever appropriate 

• Resource requirements: Staff, infrastructure, and other resources with associated costing 

• Implementation schedule: The implementation schedule contains information regarding the 
timing and dependencies between the items identified in the WBS 

• Change management plan: The approach to ensure that implementation follows the path of 
least possible resistance 

8.2.2 Collect and analyze feedback 

During the review process, all feedback is recorded, dispensed and consolidated. Follow-up actions 
are documented and tracked through to completion. 

8.2.3 Develop the final transformation blueprint 

As feedback actions are documented and closed, comments and changes are also incorporated in 
the final transformation blueprint document. 

8.2.4 Brief steering committee and obtain approval 

In this activity, a formal presentation of the blueprint is made to the Steering Committee, after 
which the decision to approve the blueprint is recorded. Any issues that arise during the final 
review are addressed and closed as needed. 

8.3 Phase-VI synopsis 


Phase VI concludes the process architecting for the sector. It results in the creation of a 
transformation blueprint. The transformation blueprint consolidates all the recommendations 
related to strategy, functions, processes, services, data, and IT solutions made in the previous 
phases. 


s. No. 

Activity 

Key inputs 

Primary outputs 

Activity owner 

Approver 

1 . 

Document and 

distribute the Draft 

Transformation 
Blueprint for review 

• SAMS 

• STAV 

• Target architecture 

model 

• Draft 

transformation 

blueprint 

SAWG - PM 
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• Target IT solution 

architecture 




2. 

Collect and analyze 
feedback 

• Draft transformation 

blueprint 

• 

SAWG - PM 


3. 

Publish the final 

Transformation 

Blueprint 

• Draft transformation 

blueprint 

• Final 

transformation 

blueprint 

SAWG - PM 

SASC 
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9 Appendix 1: Sector Architecture Mission Statement 


The Sector Architecture Mission Statement (SAMS] summarizes the foundational purpose behind the 
architecture development and traces its linkage with the overall service mission of the sector. 


Sector: 

<Name ofsector> 

Organizational units: 

Ministry 



Departments 

i. 



ii. 



iii. 


Autonomous 

i. 


organizations 

ii. 



iii. 


PSUs 

i. 



ii. 



iii. 

Sector mission 


Main services delivered 

i. 



ii. 



iii. 


Architecture Mission 



statement 
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10 Appendix 2: Sector Architecture Working Group Team Roster 


The team roster contains organizational and contact information regarding the members of the 
Sector Architecture Unit (SAWG), a standing committee assigned the mandate to manage the 
architecture development. 


s. No. 

Name 

Title 

Organization 

Email 

Office Phone 

Cell Phone 
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11 Appendix 3: Sector Architecture Project Charter 

The project charter is the official authorization for the project team to undertake the activities 
prescribed in the GPAF. 

Project purpose 

[Describe the purpose of the project] 

Organizational context 

[Describe the Executive Sponsor, the participants, and the external interfaces (organizations]] 
Alignment with mission 

[Describe how the project aligns with the mission of the sector] 

Project assumptions 

[Describe any assumptions of the project] 

Project constraints 

[Describe any constraints on the project (e.g. Cost, schedule]] 

Project scope 

[Describe the activities that the core project team will undertake and their expected effect on the 
organization.] 

Out of Scope 

[Describe those objectives that may be outside the scope of the project] 

Project authorization 

[Provide statement or reference to statement by the authorizing authority] 

Core Project Team Members: 

[List the SAWG members of the project] 

External stakeholders 

[List the external stakeholder of the project] 
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Other project resources 


[Describe other resources required by the project team] 
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12 Appendix 4: Sector Abstract 

This artifact describes the main activities of the sector in brief It serves like a set of notes that the 
analyst uses to get an insight into the sector. 

Sector 

[Name the sector] 

Sector mission 

[Articulate the main purpose for the existence of the units within the sector] 

Services overview 

List the services currently offered by the sector 
Plans 

[Describe any plans and strategies for the sector] 

Organization structure 

[List the ministries, departments, autonomous organizations, and other organization units 
comprising the sector.] 

[For each organization unit, describe the following: 

i. Organization unit name 

ii. Functional divisions and sub-divisions 

iii. Services delivered 

iv. IT systems in use] 

Key stakeholders 

[Describe the main stakeholders in the activities of the sector.] 

Actor catalogue 


[Create a list of key personnel in the sector along with their roles.] 


Organizational unit 

Role 

Name 

e.g. Division 1 

e.g. Manage grievance handling 
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13 Appendix 5: Stakeholder catalogue 


This artifact identifies the groups with a significant stake in the success of the architecture project. 
Stakeholders can be categorized as: 

• Citizens 

• Suppliers 

• General staff 

• Decision-makers 

• Policy makers 

• Auditors 

Some simplified examples are given below. 


s. 

No. 

Stakeholder 

profile 

Stakeholder 

category 

Level of 

involvement 

(High/ 

Medium/ 

Low) 

Need description 

Management strategy 


[Profile the 
stakeholder] 

[Category 
e.g. citizen, 

employee, 
vendor] 

[Degree of 
stake] 

[Description of the need] 

[Determine the nature and frequency 
of interaction with these 

stakeholders (regular, at the end, at 
the start) 

Is approval required from them (if 
yes, which artifacts)? 

Evolve the communication strategy 
(awareness, training)] 

E.g. 

Citizens who 

need 

passports 

Citizen 

High 

Speedy service 

Traceability 

Set up a portal or social media group 

Awareness sessions 

E.g. 

Road 

contractors 

Supplier 

High 

Transparency 

Have focused group discussions 

E.g. 

Employees 

General staff 

Medium 

Attendance and leave system is 
optimized 

Awareness sessions 

E.g. 

Senior 

leadership 

Decision¬ 

makers 

High 

Information availability 

Seek prior approval. 

E.g. 

Minister 

Policy maker 

Medium 

Project tracking 

Keep informed 
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14 Appendix 6: SWOT report 


This is a technique for identifying the capabilities of an organization, throwing up alerts (if any], and 
highlighting opportunities for development in the future. 


Strengths 

Weaknesses 

Identify all strengths that exist currently (and are known prior to 
the architecting process). 

Identify all weaknesses that exist currently (and are known prior 
to the architecting process). 

E.g. The department has excellent relationships with suppliers. 

E.g. Data is scattered amongst multiple sources, and often 
duplicated. 

Opportunities 

Threats 

Identify existing gaps and future opportunities that are potential 
strengths. 

Also, identify any threats that exist, as they are potential future 
weaknesses. 

E.g. There is a strong demand to provide status reports (on the 
implementation of various services]. 

E.g. Technology is changing so rapidly that systems developed a few 
years ago are becoming obsolete. 
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15 Appendix 7: Strategic transformation options 


This artifact assesses the impact of the capability analysis (SWOT] on process and technology and 
arrives at actionable strategic options. 

Impact analysis 

[Assess the impact of the various strengths, weaknesses, opportunities, and threats] 



Enterprise 

architecture 

impact 

Service impact 

Process impact 

Technology 

impact 

Strategic option 

Strength 







[Does the strength 
impact enterprise 
architecture? If not, 

can it have a 
potential future 

impact?] 

[Does the strength 
impact the services 
delivered? If not, 

can it have a 
potential future 

impact?] 

[Does the strength 
impact 

organizational 
processes? If not, 
can it have a 
potential future 

impact?] 

[Does the strength 
impact IT system 
performance? If 

not, can it have a 
potential future 

impact?] 

[Describe how the 
strength be 

exploited further to 
streamline services, 
processes, and 

technological 
systems.] 

i. 






ii. 






Weakness 







[Does the weakness 
impact enterprise 
architecture? If not, 

can it have a 
potential future 

impact?] 

[Does the weakness 
impact the services 
delivered? If not, 

can it have a 
potential future 

impact?] 

[Does the weakness 
impact 

organizational 
processes? If not, 
can it have a 
potential future 

impact?] 

[Does the weakness 
impact IT system 
performance? If 

not, can it have a 
potential future 

impact?] 

[How can the 

impact of the 

weakness on 

services, processes, 
and technological 
systems be 

reduced?] 

i. 






ii. 






Opportunity 







[Can the 

opportunity have a 
potential impact on 
enterprise 
architecture?] 

[Can the 

opportunity impact 
the services 

delivered? 

[Can the 

opportunity impact 
organizational 
processes?] 

[Can the 

opportunity impact 
IT system 

performance?] 

How can the 

opportunity be 

exploited to 

streamline services, 
processes, and 

technological 
systems. 
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i. 






ii. 






Threat 







[Can the threat 

have a potential 
impact on 

enterprise 
architecture?] 

[Can the threat 
impact the services 
delivered? 

[Can the threat 
impact 

organizational 

processes?] 

[Can the threat 
impact IT system 
performance?] 

How can the threat 

be countered to 

streamline services, 
processes, and 

technological 
systems. 

i. 






ii. 







Prioritization of strategic options 

[Consolidate and prioritize the strategic options identified above into a list of actionable 
recommendations.] 


Strategic 

option 

Option 

description 

Assumptions 

Selection Criteria 




Investment 

Reality 

Driver 

Urgency 

Technical 

Risk 

Work 

Force 

Time to 

Implement 

Citizen 

Benefit 

Mission 

Impact 






























































Actionable recommendations 


[From the above table, extract strategic options that are potential transformational prospects and 
actionable at some point in the future.] 


Option 

Option 

description 

Selection Criteria 

Totals 



Investment 

Reality 

Driver 

Urgency 

Technical 

Risk 

Work 

Force 

Time to 

Implement 

Citizen 

Benefit 

Mission 

Impact 
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Option 

Option 

description 

Selection Criteria 

Totals 



Investment 

Reality 

Driver 

Urgency 

Technical 

Risk 

Work 

Force 

Time to 

Implement 

Citizen 

Benefit 

Mission 

Impact 
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16 Appendix 8: Risk catalogue 


A summary of the risks facing the architecture project 


ID 

Risk 

Labe 

1 

Risk 

Descriptio 

n 

Risk 

Category 

Severity 

Probabilit 

y 

Risk 

Priorit 

y 

Submitte 
d by 

Date 

Identifie 

d 

Risk 

Owner 

Mitigatio 
n Plan 

Unique 

Brief 

Provide a 

Enter a 

What is 

What is 

Enter 

Enter the 

Date the 

Name of 

What is 

ID 

label 

more 

category 

the 

the 

the 

name of 

risk was 

owner of 

the 

tracking 

for 

detailed 

descriptio 

severity 

likelihood 

overall 

the 

identifie 

the risk. 

overall 

number 

the 

description 

n (i.e., 

of the 

that the 

priority 

person 

d 

risk 

plan to 

for each 

risk 

of the risk 

type) of 

risk to 

risk may 

of the 

who 


owner is 

reduce 

Risk 


including 

the risk. 

the 

occur 

risk 

identified 


responsibl 

the 

identifie 


the 

Examples 

project 

[H/M/L) 

[H/M/L 

the risk 


e for 

probabilit 

d 


expected 

include 

scope, 


) 



tracking 

y or effect 



impact if 

mission, 

schedule 





and 

of the 



the risk 

people, 

, and 





reporting 

risk? 



occurs 

process, 

resource 





on the 





cost, data, 

s if it 





status of 





privacy, 

occurs 





the risk 





security, 

[H/M/L) 





and any 





and 






associated 





technology 






response 





0 






plans 


1 











2 











3 
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17 Appendix 9: Sector Target Architecture Vision 


This artifact draws on the architecture mission, sector capability analysis, and architecture strategy to 
prepare a vision statement that outlines what the key stakeholders should expect from the 
architecting exercise. 


No detailed format has been prescribed, but a simplified vision statement has been given below (only 
for illustrating the concept). This vision statement is for a single division within a department. In 
actual practice, a vision statement for an entire sector could be more complex. 


Mission 


Vision 


To facilitate speedy 
redress of citizen 
complaints 


Single-window for citizens 

Citizens know where to post their 
complaints and do not need to know the 
internal structure of the government 

Filter spam 

Departments do not get distracted from 
handling genuine complaints 

Provide prioritization assistance 

Complaints receive attention that is 
commensurate to the seriousness of the 
complaint 

De-duplicate 

Complaints sent multiple times (or through 
multiple channels) are linked together and 
treated as a single mail 

Provide precedents 

Departments can get access to valuable 
inputs from similar cases received in the 
past in other departments 

Tracking assistance to citizens 

Citizens are given regular or on-demand 
reports on the status of the complaint 

Follow up with concerned departments 

Departments are reminded about the 
status of the complaint and asked to 
follow-up 
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18 Appendix 10: Function model 


This artifact describes the functions within the organizations in the sector. A function is a group of 
activities related by some common factor (usually expertise). The model will undergo changes during 
the course of the architecture exercise beginning with the baseline version (current functions) and 
concluding with the target version. 


Repeat this exercise for all functional areas, divisions, sections. The level of granularity to which 
activities should be decomposed can vary. The OPOPOT (One-person-one-place-one-time) criterion has 
been found to be useful in determining granularity level. 


ID 

Organization/ Activity 
type 

Brief description 

Main services/ 

functions 

Head 

Parent 

organization/ 

activity 


Sector Ml 






Department D1 






Functional area FI 






Division VI 






Section SI 






Activity A1 






Activity A2 






Activity A3 






Department of Administrative Reforms and Public Grievances 


May 2012 


64 





















Government process architecting framework 


19 Appendix 11: Services catalogue 


The service model is a description of the services provided by the organizations within the sector. 
These services could be both external and internal. The model focuses on the interface details of a 
service and less on its internals. 

The services catalogue consists of two parts: a consolidated listing and a service description (per 
service). 


Service listing 


Service 

ID 

Service name 

Internal/ 

External 

Output 

SLA 

Interface description 

SI 






S2 






S3 






S4 






S5 






S6 







Service description 


Each service listed above is described in detail. 


Service type 


Service ID 


Service name 


Component activities 


Brief description 


Interface description 


Trigger 


Reference information 


Output information 
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20 Appendix 12: Process model 


A process is a grouping of activities that act in sequence to produce a particular output. Thus, a 
process model defers from a function model in the sequencing of activities. It also defers from the 
service model in that it goes under the hood to examine the internals of an activity. 

The diagram below illustrates a simple process model. 


Receive 
paper 
complaints 
(PI .1.11) 


Receive 

Deliver mail paper 

—to section —complaint 
(PI.1.1.2) fromCRU 

(PI .2.1.1) 


Receive 
email 
complaint 
(PI.2.1.2) 


Receive 
online 
complaint 
(PI.2.1.3) 


Enter 
complaint 
in system 
(PI.2.1.4) 


Assign 
number 
(PI .2.1. 
5) 


v 

Send 

acknowledg 
ment 
(FI.2.1.7) 


Assign 

appropri 

ate 

departm 

ent 

(PI.2.1 
6 ) 




O© 


Generat 

e 

periodic 
reports 
(FI 2.2.1 
) 


Check 
-> status 
(FI.2.2.2 
) I 


Send 

reminder 

s 


(FI .2.2.3) 




Send 

status 

update 


CD© 


Department of Administrative Reforms and Public Grievances 


May 2012 


67 




















Government process architecting framework 


21 Appendix 13: Use case catalogue 


A use case is a detailed description of an activity. It is used by the function and process models and can 
itself refined during the course of the architecting process - starting with a baseline version and 
ending with a target use case. 

A use case catalogue is the set of all use cases in the organization (sector). 


Use case ID 


Activity ID 

Unique identifier 

Activity type 


Activity name 

A short active verb phrase, indicating the goal 

Component 

The business or application component that uses this activity to 
deliver a service 

Brief description 

Where the name is insufficient, add a sentence stating the purpose. 

Primary actor 

Role name or description of the primary actor 

Trigger 

What causes the process to start - event, message or time event 

Input 

Data carried as arguments in the input message, with types 

Output 

Data output or returned at the end of the process, with types 

Pre-conditions 

The state the world must be in for the process to work 

Post conditions 

The state of the world after the process finishes. 

Main Success End Condition: the state upon successful completion. 

Alternative End Conditions: the state if goal abandoned, may imply 
handling side effects 

Logic (see diagram] 
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Main success path 

See swim-lane diagram 

Alternative paths 

See swim-lane diagram 

Non-functional characteristics 

Duration target 

The amount of time this process should take, average and maximum 

Frequency 

How often the process is expected to occur, peak times and loads 

Cross-references to other artifacts 

Locations 

Locations where process is invoked or executed 

Used processes 

Processes used, and whether the use is a dependency or not 

Consumer processes 

Processes that use this one 

I/O components 

UI definitions 

Data references 

Persistent entities accessed 

Secondary actors 

Other actors, systems or components the process needs 

Requirements 

Requirements supported 
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22 Appendix 14: Information entity model 


This artifact describes the key data entities that are used by the various processes and services. The 
model can have various versions beginning with a baseline version and ending with the target model 
as the architecting proceeds and enhancement prospects are identified. 


Entity ID 

Entity name 

Brief description 

Source 

Key data elements 
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23 Appendix 15: Service - data matrix 

This artifact establishes the relationship between information entities and the services that reference 
them. 

A service could act on an entity in one of the following ways: 

i. Create (an instance of the entity) 

ii. Refer (to the entity) 

in. Update (an instance of the entity) 
iv. Delete (Delete an instance of the entity) 

[Use the services and entity catalogues to create this matrix of service versus entity.] 



Entity ID 

El 

E2 

E3 

E4 

E5 

E6 

E7 

E8 


Entity name 









ID 

Service name 









SI 


R 

R 

c 

R 


R 



S2 




U 

R 


R 



S3 




u 

R 

c 

R 



S4 




R 

R 


R 



S5 




R 

R 


R 

c 


S6 




R 

R 


R 

R 

c 


Legend 

C: Create, R: Read, U: Update, D: Delete 
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24 Appendix 16: Baseline IT systems survey 


This artifact surveys the current IT systems and assesses their relevance in the context of the current 
and target architecture models. 


System 

ID 

System name 

Brief description 
of functionality 

Technology 

Services 

provided 

Procurement/ 

development 

history 

Cost 
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25 Appendix 17: Baseline system performance report 


This artifact assesses the performance of the IT systems currently in use within the sector. Sample 
criteria are given in the table below. The various IT systems can be rated based on these criteria. 


Criteria 

Score description 

Low 

(1) 

Medium 

(3) 

High 

(5) 

PI 

System capability for supporting associated strategic goals and objectives 




P2 

Extent of stakeholders’ feedback for performance measurement and system refinement. 




P3 

Demonstrate a projected return on investment that is clearly equal to or better than 
alternative uses of available resources (i.e. enterprise products or services). 




B1 

Lack of functional overlap with other systems. 




B2 

System incorporates re-engineered/streamlined business processes (workflow) in an 
automated fashion that supporting strategic goals and objectives 




D1 

Existence and documentation of data standards and quality control procedures. 




D2 

Relative maturity of system's data storage and access methods. 




D3 

Relative redundancy of system data 




At 

Degree of enterprise architectural compliance 




A2 

Extent to which system design requirements are defined and documented. 




A3 

Extent to which system interfaces are defined and documented. 




A4 

Extent to which high-level design or operational concepts are defined. 




A5 

No alternative private sector or governmental source can efficiently support the function. 




T1 

Extent of compliance with standards, protocols and best practices. 




T2 

Extent of maximum use of shared, existing infrastructure components and services. 




SI 

Extent to which the system complies with current security requirements and extent of 
progress through the C&A process 




SMI 

System deployments are modular and are/have been performed in phases based on mission 
needs 




SM2 

Existing Acquisition and Funding Strategy is appropriate to support mission needs as an 
enterprise service 
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SM3 

Existing Project/Systems have been identified as candidates for target Service needs 
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26 Appendix 18: Target IT solution architecture 


Based on the baseline IT system performance report , a list of proposed IT solutions can be developed. 


System 

ID 

System 

name 

Brief 

description of 
functionality 

Enhancement/ 

new 

Technology 

Services 

provided 

Development/ 

COTS 

Cost 
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27 Appendix 19: Process maturity model 


Process maturity reflects how close an organization is to being capable of innovating and improving 
continuously. Achieving process maturity is one of the goals of a process architecture. There are 
various internationally accepted models for assessing process maturity. This appendix advocates the 
use of the Business Process Maturity Model (BPMM), developed by the Object Management Group 
(OMG), a not for profit international industry consortium. 

The model describes an evolutionary improvement path that guides organisations in moving from 
immature, inconsistent processes to mature, disciplined processes. In following the BPMM 
improvement path, organisational behaviour and culture will change allowing the organisation to 
produce continually improving business results. 

The five levels of maturity guide an organisation to evolving from poorly defined and inconsistent 
practices, to repeatable practices at the unit level, to standard organisation-wide end-to-end business 
processes, to statistically managed and predictable processes and finally to continuous process 
innovation and optimisation. 

The five maturity levels can be briefly described in terms of their management focus and primary 
objective: 

Initial - "Fire-fighting management" - There are no specific objectives. Success in these organisations 
depends on the competence and heroics of the people in the organisation and not on the use of proven 
processes. 

Managed - "Work unit management" - The objective is to create a management foundation within each 
work unit or project. 39 

Standardised - "Process management" - The objective is to establish and use a common organisational 
process infrastructure and associated process assets to achieve consistency in how work is performed to 
provide the organisation's products and services. 

Predictable - "Capability management" - The objective is to manage and exploit the capability of the 
organisational process infrastructure and associated process assets to achieve predictable results with 
controlled variation. 

Innovating - "Change management" - The objective is to continuously improve the organisation's 
processes and the resulting products and services through defect and problem prevention, continuous 
capability, and planned innovative improvements. 

The table below summarizes this maturity model. 
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Maturity Level 5 
Innovating 


Maturity Level 4 
Predictable 


Maturity Level 3 
Standardised 


Maturity Level 2 
Managed 


Maturity Level 1 
Initial 


Implement continuous proactive 
improvements to achieve 
business goals 


Manage process and results 
quantitatively and exploit benefits of 
standardisation 


Develop standard processes, 
measures, and training for product 
and service offerings 


Build disciplined work unit 
management to stabilise work and 
control commitments 


Motivate people to overcome 
problems and just “get the job done’ 


Planned innovations 
Change management 
Capable processes 


Stable processes 

Reuse / knowledge management 

Predictable results 


Productivity growth 
Effective automation 
Economy of scale 


Repeatable practices 
Reduced rework 
Satisfied commitments 


Ad hoc processes 
Inconsistent outcomes 
Rework 
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28 Appendix 20: Architecture capability maturity model 


Architecture capability maturity reflects how close an organization is to a state where its process 
architecture evolves dynamically through an established internal process. A number of international 
models exist, which can be customized to fit into government process architecture. This appendix 
presents the following alternative models: 

i. Government Process Architecture Capability Maturity (GPACM]: Model A 

ii. Government Process Architecture Capability Maturity (GPACM]: Model B 


28.1 Government Process Architecture Capability Maturity [GPACM]: Model A 

We may conceptualize a four level process capability starting from a Basic Foundational 
Process Automation to a Standardized System/ Solution Architecture, Enhanced functional 
architecture and at the highest level depicting process capability, the Intelligent System 
Architecture. These four levels of process capability and maturity are detailed below. 

Level 1: Basic Foundational Process Automation [GFPA] 

• Brainstorming and documentation of business objectives and mandates 

• Study and documentation of operations/ functions and listing of processes 

• Specifying details of organization of work and earmarking teams/resources 

• Specification & detailing the roles and responsibility matrix 

• Detailing the process flow for each of the processes (in the form of process flow 
diagrams] 

• Specifying business rules for compliance 

Level 2: Standardized System/Solution Architecture (SSA] 

• Implementing alternate flows/ contingent process pathways following event triggers, 
exceptions, alerts 

• Access control based on user profile and on the basis of need to know/operate 

• Validation while filling data entry, transactions 

• Execution, instructions and talk back features 

• Modularity 
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• Scalability 

• Configuration management - re configuring roles, rules 

• Control of software behavior 

• Reporting 

• Audit trails 

• Backup & restore operations 

• Encrypted access & security features 

• System outrages & fall back options to transact manually & thereafter restoration of 
online operations 

Level 3: Enhanced Functional Architecture [EFA] 

• Maturity of form based transactions 

• Engaging gui with features such as context help, navigation aids, tool tips, progressive 
drilldown features, 

• Cross references, alerts and exceptions 

• Save & resume operations 

• Fault diagnosis 

• Role centered dashboards 

• Activity logging, use of metrics & performance tracking 

• Dynamic interfacing of forms 

• Disaster recovery, snapshots, roll back features 

• Interoperability and interface design 

• Data migration 

Level 4: Intelligent System Architecture (ISA] 

• Self healing architecture - autonomous response for fault detection, recovery 

• Use of auto responders 
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• Defining default mode of operations and other types of system operative modes and 
corresponding system behavior 

28.2 Government Process Architecture Capability Maturity [GPACM]: Model B 


This is an alternative model that is customized from internationally used models and can be used to 
assess the process architecture capability maturity of a government organization. It assesses maturity 
along five levels depending on whether a standard defined re-usable framework exists, which tracks and 
analyzes performance metrics. These levels are briefly described below: 

GPAO - Initial 

No documented process architectural framework exists at this level of maturity. While solutions are 
developed and implemented, this is done with no recognized standards or base practices. The 
organization is completely reliant on the knowledge of individual contributors. 

GPA1 - Informal 

The base process architecture framework and standards have been defined but they are rarely used and 
verified. Organizations with an architecture framework at this level are still dependent on the 
knowledge of individual contributors. 

GPA2 - Re-usable 

The base architecture and standards have been identified and are being tracked and verified. At this 
point in the program processes are repeatable and reusable templates are starting to emerge. 

GPA3 - Standard 

The architecture framework is well defined; using approved standards and customized versions of the 
templates. Processes are documented across the organization and are being tracked. Performance 
metrics are collected, analyzed and acted upon. The metrics are used to predict performance and 
provide better understanding of the processes and capabilities. 

GPA5 - Dynamic 

The processes are mature; targets have been set for effectiveness and efficiency based on business and 
technical goals. There are ongoing refinements and improvements based on the understanding of the 
impact changes have to these processes. 
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29 Appendix 21: Competency assessment framework 


The GPAF recommends that, as far as possible, the Sector Architecture Working Group (SAWG] be 
staffed with government officers. To effectively contribute to the working group, government 
employees need to have specific competencies. These competencies are: 

• Generic skills - leadership, teamwork, inter-personal skills 

• Functional skills - business cases, business process, strategic planning 

• Enterprise architecture skills - modeling, building block design, applications and role 
design, systems integration 

• Program or project management skills - managing change, project management methods 
and tools 

• General IT knowledge - top-level knowledge of applications, asset management, migration 
planning, and service level agreements (SLAs] 

• Technical IT skills - software engineering, security, data interchange, data management 

• Legal environment - data protection laws, contract law, procurement law, and fraud 

Assessing whether an officer of the Government of India possess one or more of these skills 
requires a suitably tailored competency assessment framework. Such a framework will contain 
tests that display characteristics of, validity, reproducibility, and feasibility. 

Validity 

A test is valid if it measures what we really wish to measure. For example, the ability to 
comprehend and understand the operations and functions being carried out in a given 
department or organisational unit is not a valid test of the subject's ability to produce 
documentation capturing the functional requirements of processes. This type of validity is 
called content validity. 

There is also a concept of predictive validity. For example, does an evaluation or 
assessment designed for testing knowledge of operations/ functions carried out in an 
organizational unit predict the subject's competence in undertaking a process analysis to 
enable him reengineer them optimally? 

Reproducibility 

A reliable test should produce reproducible results. The results should be similar at all 
times. 
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Feasibility 

Feasibility refers to the time involved in developing, administering, scoring, interpreting 
and reporting a test, which should be justifiable. 

The most commonly adopted approach is to have multiple exercises or simulations designed to 
replicate the tasks and demands of the job for which a candidate is being considered. These 
exercises or simulations are designed in such a way that candidates can undertake them singly or in 
groups, and under the watchful eyes of assessors. 

Most often, progressive development and assessment of competencies can be integrated with a 
structured training programme. A valid, reliable, and feasible assessment process will need to take 
into consideration the following: 

• The overall purpose of the assessment system must be documented and made known to the 
trainees being assessed. 

• The purpose of every component of the assessment system must be specified and available 
to the trainees, educators, and employers. 

• The sequence of assessments must match the progression through the competency 
development pathway. 

• Assessments would need to build on previous assessments. 

• Assessments will need to systematically sample the entire content, appropriate to the stage 
of training, with reference to the common and important aspects and problems 
characterizing the domain. 

• Methods will be chosen on the basis of validity, reliability, feasibility, cost effectiveness, 
opportunities for feedback, and impact on learning. 

• The rationale for the choice of each assessment method will be documented and evidence- 
based. 

• The methods used to set standards for classification of trainee's performance/ competence 
will require to be transparent. 

• Assessments must provide relevant feedback. 

Each sector can adopt its own competency assessment framework. Here are the general steps: 

• Identify a suitable competency model and finalize it in consultation with the ministry/ 
department, for the targeted group of employees. 

• Measure and map the competencies of each employee in the target group. 
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• Analyze competency gaps of individual employees in the target group. 

• Recommend areas of improvement. 


Department of Administrative Reforms and Public Grievances 


May 2012 


83 



